<div id="copy">
	
<div id="sidebar">
	<hr/>
	<a href="#server-mode">Server Mode</a>
	<hr/>
	<a href="#rollout">Roll Out</a>
	<hr/>
	<a href="#logging">Logging</a>
	<hr/>
</div>

<div id="bodyCopy">
	<span id="floatLeft"><img src="/img/cc-bynd-mr-t-in-dc-flickr-4286854004.jpg" width=280px alt="Deployment"/></span>
	<h3 id="server-mode">Server Mode</h3>
	<p>Gobl can be deployed in one of the following modes: live-update mode and bunker mode.
	</p>
	<p><em>Live-update mode</em> means that content can be updated without re-starting the server (a.k.a. hot-swapped in the hardware world).  This is normal / expected mode.
	</p>
	<p><em>Bunker mode</em> essentially disables any update.  The only way to update the site is by restarting the server.  This mode is applicable only in a security paranoid setting.  Obviously, if you only have a single production server, then a restart will bring the site down (for one minute).  But if you have more than one server, then you can avoid down time by letting your load balancer do the smart work.
	</p>
	
	<h3 id="rollout">Roll Out</h3>
	
	<p>Web site deployment involves business process, not just technical process.  Different web site / project / company can have different deployment process.
	</p>
	<p>I assume you will use separate staging and production server; at least logically separate, if not physically separate.  In staging server, you obviously need to run it in live-update mode, so you can make changes dynamically on the fly.  In production server, you can use either live-update mode or bunker mode.
	</p>
	<p>Here is a scenario for workflow taken from my personal workflow for this web site.
	</p>
	<ol>
		<li>Create / edit marked up contents in a text editor.  (I use <a href="http://geany.org/" title="Geany">Geany</a>.)</li>
		<li>QC the pages by running Gobl as localhost.</li>
		<li>Move files to production server via Mercurial (or Git or whatever VCS you use).</li>
		<li>Perform <span id="code">gobl update</span> in production server which is running in live-update mode.</li>
	</ol>
	<p>The workflow for a large enterprise web site, depending on your project and organisation, can be more involved.  Actual steps and actors will vary, but the following scenario simulates an enterprise web site work flow.  Remember, this is only an illustration.
	</p>
	<ol>
		<li>You may have copy writer(s) - this could be just you - who develop the content copy.  The copy can be written in any editor.</li>
		<li>Mark up or edit the copy in your favourite HTML editor.  Adjust the CSS/JS if needed.</li>
		<li>Copy the marked up contents into Gobl staging server and do QC there.</li>
		<li>Version control the files.</li>
		<li>Reviewers then access the staging server to review and comment.</li>
		<li>Repeat the process for final QC.</li>
		<li>Copy the files to production server.</li>
		<li>Perform <span id="code">gobl update</span> to update the production server with the latest changes.  (This assumes you use live-update mode.)</li>
	</ol>
	<p>Those who manage the deployment to the staging server can be different from those who actually manage the deployment to production server.</p>
				
	<h3 id="logging">Gobl Logging</h3>
	
	<p>Gobl has system logging and web logging.  <em>System log</em> records messages that the server spits out from time to time, such as errors.  <em>Web log</em> records which page was served to which ip address and when.
	</p>
	<p>System log file, by default, are saved on the same machine as the web server.  Web logs are spit out to Gobl web logger on another machine / server in the network (at a non-public address and/or behind the firewall).  The objective is to offload the burden away from the web server to the web logger so the web server can focus on serving pages only.
	</p>
	<p>Please consult the documentation in <a href="http://code.google.com/p/gobl">code.google.com/p/gobl</a> for details.</p>
	
	<br/>--<br/>
	Photo source: Fotopedia, CC-BY-ND mr-t-in-dc
</div>

</div>
